Handling ICS Enhanced and Non Enhanced MSC in a Pool

ABSTRACT

Handling core network entities of a radio core communications network comprising a first network entity and a second network entity, where the second network entity differs from the first network entity in that it is capable of processing inter-working between messages exchanged with the radio core communications network and messages exchanged with an IP multimedia subsystem. In other words, one network entity is capable of performing inter-working while the other one not. The first and/or second network entities are provided with configuration information indicating a relationship between the two network entities. Messages relating to calls established between the at least one user terminal attached to the entity non capable of inter-working and a further user terminal attached to the IP multimedia subsystem are routed according to the configuration information.

This application is a continuation of U.S. application Ser. No.13/577,474, filed 18 Sep. 2012, which was the National Stage ofInternational Application No. PCT/CN2010/000168, filed 8 Feb. 2010, thedisclosures of each of which are incorporated herein by reference intheir entirety.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to communications in a network and moreparticularly to a method, a system, corresponding and interrelatednetwork entities as well as to a computer program for handling networkentities of a radio core communications network. The radio corecommunications network comprises network entities capable ofinter-working between a radio core communications network and an IPmultimedia system and network entities which are not capable ofperforming the inter-working.

BACKGROUND

ICS (IMS centralized service, see also TS 23.292) in 3GPP is aiming tostudy the architectural requirements and alternatives for the deliveryof consistent services to the user mainly via the services centralizedin IMS domain regardless of the attached access type, e.g. CS (circuitswitched, CS) domain access or IP-CAN. It also considers how to supportthe service continuity when the user changes the access type from CSdomain to IP-CAN or vice versa even when being engaged in a mid-callservice, i.e. service continuity at domain transfer.

To deploy ICS for an existing CS network, the MSCs (Mobile SwitchingCenter) need to be upgraded to have ICS functionality, i.e. to act as aUser Agent (UA) for a CS user towards IMS domain, therefore to convertCS signaling to SIP towards IMS and vice versa

The deployment of ICS may differ from one network to another, depends onthe business plans of the network operator or depending on the currentconfiguration of the network. Some operators may choose migrating all CSusers to ICS over a long period of time, so that they may want to startwith a small step in order to minimize the efforts in networkintegration and development. Some operators may see no need to upgradeall CS users to ICS in 5 to 10 years, so that they would like torestrict the impact on the existing CS network. In both cases, theoperators would like to minimize the impact on CS network due to ICS.

The current solutions foresee that the delivery of consistent servicesshall be achieved by replacing the standard MSC capable of circuitswitched connection services with enhanced MSC. The term enhanced MSC isused in the present context to refer to network nodes like an MSC whichare capable of the above mentioned inter-working functionalities. Inthose situations wherein existing legacy MSCs (with legacy we will referto MSC which are not enhanced, or which are not capable of performinginterworking between a radio communication network and an IP multimediasubsystem) are present and are responsible for attaching user terminals,it is not possible to provide delivery of consistent services since suchlegacy non enhanced MSC are not adapted to perform registration with theIMS or handle the corresponding messages. The current solution thereforeforesees a replacement of all existing MSC in an area in order toprovide delivery of consistent services in the same area.

However, as seen above, one problem related to the existing solutions isthat it is not possible to have an ICS deployment having a minimumimpact on an already deployed existing network.

SUMMARY OF THE INVENTION

It is an object of the present invention to overcome at least some ofthe technical problems of the prior art. It is furthermore an object ofthe present invention to provide a network entity, system, method andcomputer program for handling messages between legacy networks and IPnetwork architecture while minimizing the efforts needed for systemintegration and maximizing the reuse of existing solutions, services,applications and functionalities.

According to a first aspect the present invention provides a method forhandling core network entities of a radio core communications network.The radio core communications network comprises a first network entityand a second network entity, wherein the second network entity differsfrom the first network entity in that it is capable of processinginter-working between messages exchanged with the radio corecommunications network and messages exchanged with an IP multimediasubsystem. In other words, one entity is capable of the inter-workingwhile the other entity not. The method then comprises a further step ofproviding at least one amongst the first and second network entitieswith configuration information. The configuration information indicatesa relationship between the first and second core network entities. Themethod comprises a further step of routing messages relating to callsestablished between at least one user terminal attached to the firstnetwork entity and a further user terminal attached to the IP multimediasubsystem according to the configuration information. The steps can beexecuted in sequence or in parallel according to circumstances.

According to a second aspect of the invention it is provided anattaching core network entity for a radio core communications network.The attaching core network entity comprises a communication entity and astorage entity. The communication entity is adapted to exchange messagesrelating to calls associated to at least one user terminal attached tosaid attaching core network entity through a radio network interface.The storage entity is for storing configuration information indicating arelationship between the attaching core network entity and one furthercore network entity. Furthermore, the attaching core network entitydiffers from the further core network entity in that the further corenetwork entity is adapted to process inter-working between messagesexchanged with the radio core communications network and messagesexchanged with the IP multimedia subsystem. In other words, one entityis capable of the inter-working while the other entity not. Thecommunication entity is further adapted to route the messages accordingto the configuration information.

According to a third aspect of the invention it is provided a servingcore network entity for a radio core communications network. The servingcore network entity comprises a processing entity, a forwarding entityand a storage entity. The processing entity is for processinginter-working between messages exchanged with the radio corecommunications network and messages exchanged with an IP multimediasubsystem. The forwarding entity is for forwarding messages associatedto at least one user terminal attached to an attaching core networkentity, wherein the serving core network entity differs from theattaching core network entity in that it comprises the processingentity. In other words, one entity is capable of the inter-working whilethe other entity not. The storage entity is for storing configurationinformation indicating a relationship between the serving core networkentity and the attaching core network entity. The forwarding entity isfurther adapted to forward the messages according to the configurationinformation.

According to a fourth aspect of the invention it is provided a systemfor a radio core communications network, wherein the system comprises anattaching core network entity as above described and a serving corenetwork entity as above described.

According to a fifth aspect of the invention it is provided a computerprogram for handling core network entities of a radio corecommunications network, the computer program comprising instructionsconfigured, when executed on a programmable system, to cause theprogrammable system to carry out the method as for instance describedabove.

Further advantageous embodiments are defined in the dependent claims.Further examples are provided in the description for facilitating theunderstanding of the invention and explaining further details andadvantages related to the invention.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a flow chart illustrating a method according to an embodimentof the present invention;

FIG. 2 is a schematic block diagram illustrating a network entityaccording to an embodiment of the present invention;

FIG. 3 illustrates a schematic block diagram representing a networkentity according to a further embodiment of the present invention;

FIG. 4 illustrates a schematic block diagram of a system according to anembodiment of the present invention;

FIG. 5 is a schematic block diagram illustrating a scenario to which thepresent invention can be applied;

FIG. 6 illustrates a flow chart representing an attach procedureaccording to an embodiment of the present invention;

FIG. 7 illustrates a flow chart representing a mobile originating callflow according to an embodiment of the present invention;

FIG. 8 illustrates a flow chart representing a mobile terminating callflow according to an embodiment of the present invention;

FIG. 9 illustrates a flow chart representing a user equipment UE movingout of the control of an enhanced MSC according to an embodiment of thepresent invention;

FIG. 10 illustrates a flow chart representing an administrative cancellocal update according to a further embodiment of the present invention.

DETAILED DESCRIPTION

In the following, several embodiments and examples of the presentinvention will be presented. As it will also be evident from thefollowing explanation, the different embodiments can be differentlycombined according to the principle of the invention.

With reference to FIG. 1, it will be described a first embodiment of thepresent invention relating to a method for handling core networkentities of a radio core communications network. A network entity, as itwill also be explained in the following in more detail, is used to referto one or more network devices or network nodes which implementpredetermined functions in a distributed (through a plurality of nodesor devices) or centralized (by means of a single node or device) manner.A radio core communications network (also sometimes referred to as CN inshort) represents that part of a radio communications network comprisingnetwork entities for performing routing of calls and of signalingmessages. The core network comprises all those entities of a radiocommunications network which do not directly interact with a userterminal over a radio interface. A radio core network does typically notcomprise those devices which are directly supervising the networkentities communicating with user terminals. For instance, with referenceto a UMTS network, the core network of the radio network typicallycomprises MSC devices or MSC servers. In such example, the radio accessnetwork typically comprises base stations (or node B) and radio networkcontroller (RNC nodes). The network entities or devices of the radioaccess network (also sometimes referred to as RAN in short) communicatewith the devices of the core network over dedicated interfaces.

In the present invention, the term circuit switched network will be usedto refer to those networks comprising network entities suitable tohandle circuit switched operations or circuit switched services.Examples of circuit switched services are voice calls, data calls orshort messages like SMS which are carried over the radio access and corenetwork entities according to legacy circuit switched operations.Typical examples of such networks are including GSM, GPRS or UMTSnetworks. In fact, radio access network nodes (like for instance BSC ina GSM network or an RNC in a UMTS network) or core network nodes (e.g.an MSC node) of such networks are capable of handling circuit switchedoperation or circuit switched services. With reference to a UMTSnetwork, reference is made to those parts of the UMTS network which relyon circuit switched technologies or on nodes handling circuit switchedoperations or circuit switched services among nodes of the radio accessnetwork or among nodes of the core network or between RAN and CN nodes.

Therefore, according to one example for putting the first embodimentinto practice, the method may be applied to handling MSC or MSC serversof a UMTS radio core communications network. Similarly, the presentinvention is suitable for handling core network devices of networks likeGSM, GPRS, etc. . . .

With reference to FIG. 1, the radio core communications network to whichthe method of FIG. 1 can be applied comprises a first network entity anda second network entity. The first and second network entities aredistinguished from each other. More specifically, the second networkentity differs from the first network entity in that it is capable ofprocessing interworking between messages exchanged with the radio corecommunications network and messages exchanged with an IP multimediasubsystem. In other words, the network entity is capable of processingmessages—including calls and user network signaling—received over acircuit switched access network and of interworking with messages of anIP multimedia subsystem and vice versa. In one example, the messagesreceived over the circuit switched access can be messages exchanged overan A/Iu or/and E interface while messages exchanged with the IPmultimedia subsystem could be SIP messages. In the present invention wewill refer to network entities like the second network entity abovedescribed as network entities enhanced for IMS centralized services(ICS) or in short as enhanced network entities. Network entities likethe first network entity above described will also be referred asnetwork entities non-enhanced for ICS (or, in short, non-enhancednetwork entity), since such network entities are not capable ofperforming the above mentioned interworking. In one example, the secondnetwork entity may be an MSC network node enhanced for ICS or an MSCserver enhanced for ICS. The first network entity may be according toone example a legacy MSC capable of performing only circuit switchedoperations and not capable of performing the above mentionedinterworking. Similarly, the first network entity may be an MSC servercapable of handling only legacy circuit switched operations and not theabove mentioned interworking.

The first network entity is further a network entity capable ofattaching user terminals accessing a radio communications network over aradio network interface (attaching refers to a user equipment performingthe necessary operations and steps for establishing connections in orderto access services from a network). In order to perform the attachment,network devices of the RAN may interact as known in the art. Forinstance, with reference to a UMTS network, the first network entity maybe an MSC capable of handling circuit switched communications andcapable of direct communications which an RNC node of an UMTS radioaccess network. With reference to another example applicable to a GSMnetwork, the first network entity may be an MSC capable of performingcircuit switched communications and of exchanging messages with a BTScontroller belonging to a GSM radio access network. As also mentionedabove, the referred messages can be exchanged through interfaces likethe A/Iu and/or E interface. Those messages can be user networkmessages.

In other words, the method according to the present invention is forhandling core network entities comprising at least two network entities,wherein one of them is capable of interworking messages between a radiocore communications network (like a legacy circuit switched radio corecommunications network) and an IP multimedia subsystem. The other corenetwork entity is instead not capable of performing this interworking.

The method then foresees a step S200 for providing at least one of thefirst and second network entities with configuration information,wherein the configuration information indicates a relationship betweenthe first and second core network entities. This implies that theconfiguration information may be sent to the first network entity (e.g.non ICS capable MSC) or to the second network entity (e.g. the ICScapable MSC). In another example the configuration information may besent to both the first and second network entities. As it will also beexplained in the following, according to one modification of theembodiment, the configuration information may be sent to the firstnetwork entity (i.e. the network entity not capable of saidinterworking) for handling user equipment originating calls. Accordingto another example, the configuration information may be sent to thesecond network entity capable of performing said interworking forhandling user equipment terminating calls. Thus, in case theconfiguration information is sent only to the first network entity, thismay be used for routing messages relating to calls from the userequipment to the IMS; in this example, calls originating in the IMS maynot be routed to the user equipment accessing a radio access networkover the first network entity not capable of performing theinterworking. In the example wherein only the second network entity isprovided with configuration information, it may be possible to performonly routing of calls originating from the IMS and terminating to theuser equipment accessing the network over the first network entity (i.e.being attached or being registered in the network through the firstnetwork entity) while calls originating from the user equipment may onlybe routed according to legacies circuit switched operations. In case theconfiguration information is instead provided to both the first andsecond network entities, then both UE originating and UE terminatingcalls may be provided, respectively, to/from the IMS with delivery ofconsistent services via the services centralized in the IMS domain.Further examples will be provided later in the specification showing howthe configuration information can be provided to one or both the firstand second network entities.

The method then comprises a step S300 of routing messages relating tocalls established between the user terminal above mentioned (that is,the user terminal attached to the first network entity) and a furtheruser terminal attached to the IP multimedia subsystem according to theconfiguration information. It is noted that user terminals, userequipments or mobile terminals are herein interchangeably used terms torefer to user devices capable of connecting to a network. Examples ofsuch devices are mobile telephones, laptops, PDAs etc. . . . The messageabove described may relate to the above mentioned user terminalaccessing the network through legacy circuit switched network entities;however, those messages may also refer to a plurality of user terminalsaccessing the legacy circuit switched network devices and a plurality ofuser terminals attached to the IMS. The term calls is herein used torefer to any type of connection suitable for carrying user data. Ingeneral a call refers to an exchange of data between a user terminal andanother device. Therefore, a call may comprise a voice call, a videocall, a data call, etc. . . . The call is routed to/from the firstnetwork entity, being for instance a non-enhanced MSC or a legacycircuit switched MSC, which in turn routes the call further. The abovedescribed further user terminal attached to the IP multimedia subsystemis a user terminal that may be able to access a communications networkand access a given set of services in a centralized and consistentmanner regardless of the type of access used, that is to say regardlessof whether the access occurs through a CS domain or through an IP-CAN.This is made possible by the IP multimedia subsystem to which such afurther user terminal may attach to, i.e. to which the further userterminal may register when accessing the network.

The configuration information according to the present method thereforeallow establishing a relationship or an association between the firstnetwork entity and the second network entity, i.e. it allows theestablishment on an association between a network entity which iscapable of interworking between circuit switched operations and servicesand IMS operations and services (the second core network entity) and anetwork entity (like the first core network entity) which is not capableof performing said interworking functions. On the basis of suchinformation, the routing of calls or exchange of messages relating tosuch calls may be performed. Therefore, even when accessing a networkover a legacy circuit switched network—normally not capable of handlingIMS operations or services—a user terminal is capable of using the fullcapabilities offered by the IMS since the configuration information willinstruct the first non-enhanced network entity to handle messagesthrough the second enhanced network entity. Therefore, thanks to thepresent invention, it is possible to allow users accessing a networkfrom legacy circuit switched entities to access IMS centralized serviceswithout the need to substitute or upgrade all core network entities.Consequently, an increased functionality can be achieved by means of asolution simple to realize, resulting in a limited impact on and reducedmodification of the existing deployed networks.

According to an optional modification of the first embodiment, theconfiguration information may comprise first identification informationidentifying at least the second network entity. In such case, theinformation identifying the second network entity may be communicatedonly to the first network entity which will then be able to establish arelationship with the enhanced radio core network entity. It shall benoticed that the configuration information may establish therelationship between the first and second network entities bycommunicating explicit information corresponding to the two networkentities (or, as it will be seen in the following, to more networkentities) that are to be put in relationship. According to anotherexample, the configuration information may indicate to a network entityonly the identification information of another network entity (or ofother network entities) which will be put in relationship or associationwith the network entity that receives the configuration information.According to the optional modification above introduced, the step ofrouting messages may be performed at the first core network entity andmay comprise the step of routing messages originating from the mentionedone user terminal (that is, the user terminal accessing the networkthrough a legacy circuit switched core radio network entity) through thesecond core network entity according to the first identificationinformation. In other words, according to the present modification ofthe embodiment, it is possible to communicate to the first networkentity information corresponding to the second network entity, such thatthe first network entity will be able to route calls originating fromthe user terminal accessing the legacy circuit switched network throughthe second network entity, such that this user terminal will be able toaccess services in a centralized way from the IMS thanks to theinterworking provided by the second core network entity.

It is worth noting that the configuration information according to thepresent invention establishes a relationship or an association betweentwo core network entities of a radio core communications network. Thisimplies that the invention can achieve the mentioned advantages, namelyallowing a user accessing a legacy circuit switched network to accesscentralized IMS services, by applying minor modifications on existingparts of a core radio network. In fact, it is not needed to incorporatefurther interworking nodes or gateways between a legacy network andanother network. A solution based on a gateway would in fact requirefurther adaptation and technical implementations resulting in a systemmore difficult to integrate and to upgrade, therefore also moredifficult to maintain. By applying minimal modifications to existingnodes, the present invention achieves a solution easier to deploy andmore suitable for future migrations.

The method according to the present embodiment may further andoptionally foresee that the first identification information is foridentifying at least a further network entity capable of performing theinterworking above mentioned. In other words, according to thissituation, the identification information may establish a relationshipor association between the first network entity and two or more networkentities one of which is the second network entity above mentioned. Incase the two or more further network entities are all capable of theinterworking above mentioned, the first network entity may refer to oneamong them according to situations. As it will also be explained in moredetail in the following, in fact, the first network entity may routecalls or handle corresponding messages to one of the associated enhancednetwork entities according for instance to load balancing criteria ordepending on availability of those further network devices. Forinstance, a first network entity may normally refer to the secondnetwork entity; however, in case of failure of the second networkentity, the first network entity may refer to a further network entityrepresenting a backup for the second network entity. The configurationinformation associated in the first network entity to two or morefurther core network entities may be static or dynamic, implying thatthe information can be set once for a given period of time (e.g. until anew configuration is specifically established) or dynamically. A dynamicsetting implies that the information can change over time by beingadapted or updated according to circumstances.

The method according to the first embodiment may optionally foresee thatthe configuration information comprises second identificationinformation identifying at least the mentioned first network entity,i.e. the non-enhanced first core network entity.

According to such example, the second identification information may besent to the second network entity and may comprise informationidentifying only a first network entity (or, according to anotherexample, a plurality of non-enhanced core network entities). In such acase, the second configuration information implicitly establishes aconnection between the second network entity (receiving or storing thesecond configuration information) and the identification informationrelating to the first non-enhanced core network entity. According to thepresent example, the step of routing messages may be performed at thesecond core network entity and may comprise the step of routing messagesterminating on the at least one user terminal attached to the firstnetwork entity according to the second identifying information. In otherwords, according to this example, the second network entity may performrouting calls or corresponding messages destined to the user terminalaccessing the network over the legacy circuit switched network. This isachieved by using the second identifying information indicating to theenhanced (core) network entity the non-enhanced core network entity towhich the user terminal is currently attached. Therefore, the userterminal accessing a network over a legacy circuit switched network maybe reached for termination of calls relating to services centralizedaccording to the IMS.

The method according to this embodiment may further and optionallyforesee that the relationship between the first and second core networkentities may comprise indicating that the second core network entity isa serving network entity for the first network entity. In other words,the configuration information may specify that the second network entityis the serving network entity for allowing the first network entity toaccess and perform interworking operations with the IMS. For instance,thanks to this association, the first network entity would be able torely on the second network entity for performing location updatesrelating to a user terminal attached through a legacy circuit switchednetwork. The second network entity would be the serving network entityfor such operations (like location update) or services.

The method according to the first embodiment may further and optionallyforesee that the relationship between the first and second core networkentities may comprise indicating that the second core network entity isnot a serving network entity for the first network entity. In otherwords, the configuration information may explicitly indicate that firstand second network entities are not in a given relationship or that apreviously provided relationship among those first and second networkentities is not anymore valid. Such situation may occur when performinga deregistration of a user terminal (e.g. when a user terminal isswitching off or is not anymore reachable) or when making a locationupdate in a different are such that the previously associated secondcore network entity is not anymore to be put in relationship orassociation with the first network entity. Such situation may also occurwhen the user terminal is not attached to the first network entity butto another non enhanced core network entity, such that the previousassociation or relationship needs to be explicitly cancelled byexplicitly communicating that a given relationship between those twodevices is not present. Such indication that the second network entityis not a serving network entity for the first network entity (e.g.deregistration of a user terminal) may be implemented by adding a new ormodifying an existing MAP message. A detailed example will be providedin the following.

The method according to the first embodiment may further and optionallyforesee that the configuration information is updated when the userterminal detaches from the first core network entity and attaches toanother core network entity. The step of updating comprises the deletionof previous configuration information and/or replacement of the sameconfiguration information with new one relating to the new attachingentity. Also here the implementation can be made by adding a new ormodifying an existing MAP message. Therefore, the configurationinformation are updated in order to reflect an association between thenetwork entities which are involved in providing services to a givenuser terminal. Such situation is typical of the case wherein a userterminal moves to an area such that either one or both of the first andsecond core network entities change to a new network entity not capableof performing the corresponding functions; for instance, when theattaching network entity is not capable of attaching the user terminalor maintaining the association according to the invention; or when noenhanced network entities are provided in correspondence of a givenarea. For instance, when a mobile terminal moves from a firstnon-enhanced core network entity to a further non enhanced core networkentity, the method according to the present invention may foresee thatthe configuration information are updated in order to inform the secondnetwork entity with configuration information indicating that thepreviously valid relationship between the first non-enhanced corenetwork entity and second enhanced core network entity is not anymorevalid. At the same time of thereafter, new configuration information maybe provided as being valid, which associates the further or new nonenhanced core network entity (through which the user terminal isaccessing the legacy circuit switched access network) with the secondenhanced core network entity. According to a further example, when theuser terminal moves to a new non enhanced core network entity served bya different enhanced network entity different from the initial secondnetwork entity, then the configuration information may also indicate anew relationship among the new non enhanced core network entity and thenew enhanced core network entity involved in processing the calls ormessages originating from or destined to the user terminal.

When moving away from a first non-enhanced core network entity, the userterminal may move to a new (attaching) core network entity which is anenhanced core network entity. In such case, therefore, the associationwith the second network entity may not be necessary anymore. Therefore,the configuration information may comprise void fields or may indicatethat the previously valid configuration information shall be deletedwithout providing any replacement for the same. In fact, the userterminal can now be served directly by the attaching enhanced corenetwork entity such that the configuration information can be deleted orignored.

The method according to the present embodiment may further andoptionally foresee that the second network entity may register at leastone user terminal with the IP multimedia subsystem. The registration maybe performed on the basis of the configuration information. An exampleof such operation will also be described with reference to the servingcore network entity described in FIG. 3 or with reference to the flowchart of FIG. 6. Accordingly, even when a user terminal is accessing alegacy circuit switched access network and is attached to a legacycircuit switched (e.g. non enhanced) MSC, a registration with the IMS isstill possible through the enhanced core network entity thanks to theconfiguration information establishing a relationship between thenon-enhanced and the enhanced core network entities. Consequently, auser terminal will be able to access all the IMS services in acentralized way also when accessing a network from a legacy circuitswitched access network served by a non-enhanced call network entitylike a non-enhanced MSC.

In the following, further embodiments as well as examples illustratinghow the invention can be implemented will be provided. The sameconsiderations made above with reference to the first embodiment willapply also to the following, such that the observations made above applyhere. Reference is consequently made to the above parts equivalentlyapplying to the following disclosure, which will then focus only on themain aspects necessary for clarifying each of the embodiments orexamples provided.

A second embodiment providing an attaching core network entity 100 willnow be described with reference to FIG. 2. FIG. 2 is a schematic blockdiagram comprising an attaching core network entity 100 including acommunication entity 110 and a storage entity 120. The attaching corenetwork entity is an entity comprised in a radio core communicationsnetwork as also explained above. The attaching core network entity 100may be in one example the first network entity referred to in the methodof the first embodiment. FIG. 2 also shows a user terminal 300 capableof accessing IMS services but which is however accessing acommunications network over legacy circuit switched radio access network(e.g. through nodes not capable of performing the necessaryinter-working).

The communication entity 110 is an entity adapted to exchange messagesrelating to calls associated to at least one user terminal attached tothe attaching core network entity 100 through a radio network interface.The user terminal may be attached to the network entity 100 through thecommunication entity 110 or through a dedicated attaching entity notdepicted in the figure. The radio network interface through which theuser terminal establishes communication with the radio communicationsnetwork may comprise a communication interface suitable for performingcommunication between the user terminal and one base station or aninterface that allows communication between two nodes of the radiocommunications network. According to one example, the radio networkinterface may be a Iu interface in a UMTS radio access network or an Ainterface in a GSM network. In other words, the communication entity 110is an entity that provides legacy interfaces typical of circuit switchedradio networks and which are therefore not capable of ICS, i.e. are notcapable of providing any centralized IMS services.

The storage entity 120 is an entity adapted to store configurationinformation indicating a relationship with the attaching core networkentity not depicted in FIG. 2. For the configuration information, thesame considerations apply as made above with reference to the method ofthe first embodiment. Therefore, the storage entity 120 stores therelationship between the non-enhanced (i.e. non ICS capable) networkentity 100 and another core network entity which is an enhanced corenetwork entity. The further core network entity referred to above, maybe the second network entity discussed in the above method or as alsodetailed below in corresponding examples. It is worth underlining thatthe attaching core network entity 100 of the present embodiment differsfrom the mentioned further core network entity in that the further corenetwork entity is adapted to process interworking between messagesexchanged with the radio core communications network and messagesexchanged with the IP multimedia subsystem. In other words, the storageentity 120 stores information expressing a relationship among oneattaching entity which is not ICS capable and another network entitywhich is instead ICS capable. As it will be seen in the following, MSC3is an example of an attaching core network entity 100 according to thepresent embodiment while MSCA is an example of the further core networkentity which is ICS capable, as illustrated in FIG. 5 and described incorresponding passages below.

The communication entity 110 is further adapted to route the messagesabove mentioned according to the configuration information. In otherwords, the communication entity of the attaching core network entity 100routes messages relating to calls to/from the further network entitythus allowing a user terminal attached to the non-enhanced core networkentity (i.e. through a legacy circuit switched RAN and legacy circuitswitched core network entity) so that this user terminal may access in acentralized way all services as provided through an IMS.

Therefore, thanks to the present invention and more particularly to theconfiguration information, a user terminal may be able to access IMScentralized services in a consistent way even through a non-enhancedcore network entity without the need to perform substantialmodifications or adaptation to the existing core network. Configuringthe legacy non enhanced core network entity in order to handle theconfiguration information is in fact much simpler to implement andmaintain than redeveloping the same entity or device in order to provideinterworking functionalities. Consequently, IMS centralized services areaccessible to a user terminal accessing a network through legacydevices, while maintaining the network development or integration at aminimum.

The configuration information mentioned above with reference to theattaching core network entity 100 may optionally comprise firstidentification information identifying at least the further networkentity above mentioned, wherein it is recalled that the further networkentity may be a network entity which is ICS capable. In this case, thecommunication entity 110 may be further adapted to route messagesoriginating from the mentioned at least one user terminal (attached tothe non-enhanced core radio network entity) to the further core networkentity according to the first identification information. In otherwords, according to this example, the configuration information maysimply identify the further enhanced core network entity such that arelationship is implicitly inferred by the attaching core network entity100—the relationship being between the attaching core network entity 100and the further core network entity. Accordingly, messages relating tocalls are handled according to the described association orrelationship.

The first identification information above mentioned may further andoptionally comprise information for identifying at least another networkentity capable of performing the above mentioned interworking. In otherwords, according to this example, the first identification informationmay establish a relationship between the attaching core network entity100 and two or more radio core network entities capable of performinginterworking (i.e. with two or more enhanced radio core networkentities). Therefore, the routing of the mentioned messages can beperformed to one or another enhanced core network entities depending forinstance on load balance, occurrence of failures of one of the twoentities or on other considerations according to circumstances. In thefollowing, further examples will be provided explaining furtheradvantages of the present invention.

A third embodiment of a serving core network entity will now bedescribed with reference to FIG. 3. FIG. 3 depicts a serving corenetwork entity 200 according to the third embodiment. It can be seenthat the entity 200 is capable of establishing communication with an IPmultimedia subsystem 400 and with a core network entity 100. The corenetwork entity 100 may be the attaching core network entity 100described in the second embodiment and depicted in FIG. 2. The entity100 depicted in FIG. 3 may also be represented by the first networkentity described with reference to the method of the first embodiment.The serving core network entity 200 is a network entity for a radio corecommunications network and comprises a processing entity 210, aforwarding entity 220 and a storage entity 230.

The processing entity 210 is an entity for processing interworkingbetween messages exchanged with the radio core communications network(e.g. with the device 100 and/or with further devices not depicted inFIG. 3) and messages exchanged with an IP multimedia subsystem 400.Thanks to the functionalities of the processing entity 210, the servingcore network entity 200 is an enhanced radio core network entity asdescribed above or in the following.

The forwarding entity 220 is an entity adapted to forward messagesassociated to at least one user terminal attached to an attaching corenetwork entity (of which a network entity 100 represent an example). Theserving core network entity 200 and the attaching core network entityare distinguished from each other in that the serving core networkentity differs from the attaching core network entity in that itcomprises the processing entity. In other words, the serving corenetwork entity and the attaching core network entity are different inthat the first is an enhanced core network entity while the other is anon-enhanced core network entity. The storage entity 230 stores theconfiguration information, e.g. an association between an enhanced and anon-enhanced core network entities.

The forwarding entity 220 is then adapted to forward the mentionedmessages according to the configuration information. Consequently, theserving core network entity 200 is capable of ensuring delivery ofconsistent services via the services centralized in an IMS domain alsoto users being attached to a non-enhanced core network entity on thebasis of the configuration information. Consequently, the presentinvention is capable of extending the delivery of consistent servicesvia an IMS domain to several user terminals without the need to upgradeand modify all the core radio network entities of a given network. Tothe contrary, the invention requires that only a limited number ofentities are to be upgraded to enhanced network entities which arecapable of providing the necessary services on the basis of theconfiguration information. Therefore, the solution proposed by thepresent invention requires less impact on the existing networks througha simple to implement solution.

The messages forwarded by the forwarding entity 220 may comprise,according to one example, messages relating to calls associated to theat least one user terminal mentioned above. In other words, the messagesrepresent calls which are routed according to the configurationinformation. According to this example, therefore, the serving corenetwork entity 200 is capable of forwarding messages relating to callson the basis of the configuration information expressing an associationbetween an enhanced and a non-enhanced radio core network entity.

According to another example, the messages forwarded by the forwardingentity 220 comprise at least a registration message for registering theat least one user terminal with the IP multimedia subsystem on the basisof the configuration information. An example of implementing thismodification of the third embodiment will be provided in the followingwith reference for instance to FIG. 6. In other words, when a messageforwarded by the forwarding entity 220 comprises a registration message,the serving core network entity is capable of performing a registrationwith the IMS of a user terminal accessing a network over a legacycircuit switched network and when the user terminal is attached to anon-enhanced core network entity. That is to say, the user terminal iscapable of registering with the IMS and therefore using thecorresponding services thanks to the special arrangement based on theconfiguration information without the need to attach to an enhanced corenetwork entity as instead required in the current state of the art.Therefore, in order to allow user terminals to access IMS services, itis not necessary to modify all core network entities in order to performinterworking. To the contrary, only minor adaptations or upgrades areneeded in the network according to the present invention.

The configuration information may optionally comprise identificationinformation identifying at least one attaching network entity, whereinthe attaching network entity may be the entity 100 described withreference to the second embodiment or the first network entity describedwith reference to the first embodiment. In such case, the forwardingentity is further and optionally adapted to route messages terminatingon the at least one user terminal (i.e. the user terminal accessing acommunications network from a legacy circuit switched RAN and beingattached to a legacy circuit switched core network entity) according tothe above mentioned identifying information. This implies that messagesare forwarded to the non ICS capable core network entity specified inthe identification information comprised in the configurationinformation.

Therefore, the serving core network entity according to the thirdembodiment is capable of registering user terminals with an IMS networkor handling calls relating to corresponding services for user terminalswhich are attached to non-enhanced core network entities thanks to theconfiguration information. This leads to the advantage that userterminals can access IMS centralized services without the need to deployinterworking functions on all core network entities but only on alimited number of them. This results in an easy to implement solution.

A fourth embodiment of a system for a radio core communications networkwill now be described with reference to FIG. 4. The system comprises atleast an attaching core network entity and at least a serving corenetwork entity. The attaching network entity 100 of the secondembodiment may be an example of a serving core network entity 4200 ofFIG. 4. Moreover, the first and second network entities described withreference to the first embodiment may represent examples of,respectively, the attaching core network entity 4100 and serving corenetwork entity 4200 depicted in FIG. 4. Therefore, similarconsiderations made above apply to the network entities of the system ofFIG. 4. Thanks to the configuration information, the attaching corenetwork entity 4100 is capable of exchanging messages with the servingcore network entity 4200 such that a user terminal attached to thenon-enhanced core network entity is capable of registering andexchanging messages with the IMS through the enhanced core networkentity 4200 to which the network entity 4100 is associated through theconfiguration information. The same applies for the serving core networkentity 4200, which is capable of performing actual registration orrouting calls terminated at the mentioned user terminal by referring tothe serving core network entity on the basis of the configurationinformation.

The system of FIG. 4 may optionally comprise a database 4500 for storingthe configuration information and for forwarding the configuration to atleast one among the attaching core network entity and the serving corenetwork entity. The database 4500 may be comprised in a further networkentity capable of determining the configuration information which arethen stored in the database. The determination of the configurationinformation can be done in a static way (e.g. once for all or for agiven period of time until a new configuration or maintenance occurs) oron a dynamic way such that they are changed and adapted according tocircumstances or network conditions. As also explained in the following,an HLR is an example of implementing the database 4500 according to thepresent invention.

According to another embodiment, the present invention also foresees acomputer program for handling core network entities of a radio corecommunications network wherein the computer program comprisesinstructions which are configured, when executed on a programmablesystem, to cause the programmable system to execute or carry out thesteps of the method according to the first embodiment above described.In fact, as also apparent to the reader, the present invention may berealized through a computer program specifically adapted to execute themethod according to the present invention. The computer system forexecuting the computer program comprises typical entities necessary forexecuting instructions like a processing entity or unit, memory(volatile or non-volatile, like RAM, ROM, hard disks, etc. . . . ) andinput and/or output devices as necessary.

As also evident to the skilled person, the present invention can in factbe implemented by hardware, software or any combinations thereof as moresuitable according to circumstances. Moreover, the invention or partsthereof may be implemented in a distributed or centralized manneraccording to circumstances.

In the following, examples will be provided showing how the invention orits different embodiments can be put into practice. Moreover, exampleswill be provided showing how different procedures can be executedaccording to the principle of the present invention.

FIG. 5 illustrates a situation representing one way of minimizing theimpact on circuit switched network when wanting to provide IMScentralized service also through a legacy circuit switched network. TheMSCs of FIG. 5 are examples of the network entities of a radio corenetwork according to the invention. The configuration represented inFIG. 5 foresees keeping the existing MSC nodes almost untouched and justupgrading or adding a few ICS enhanced MSC nodes in the network in orderto handle all the ICS related traffic in the network.

As already mentioned in the opening part of the present specification,current solutions do not fulfil the requirements for operating such anetwork solution. For this reason, current prior art solutions foreseethe upgrade and replacement of all legacy MSCs with upgraded or enhancedMSCs thus implying a major impact on the deployment of networks. Asshown in FIG. 5, supposing that MSCA and MSCB are ICS capable, thefinding of the invention is based on making MSCA and MSCB working as theICS agents for all the other MSCs (which are non-enhanced MSC) such thatthe traffic to/from the other MSCs will go through MSC A/B which willact as ICS user agent for the subscribers. However, according to thecurrent known solutions, when the user equipment switches on, it willmake a location update such that the HLR will get the user equipmentslocation pointing to MSC3. When the user equipment moves to MSC5, theHLR will then have its new location pointing to MSC5. Consequently,since the nodes MSC3 and MSC5 are non ICS capable, the user will not beable to register with the IMS network and will not be able to useservices in a centralized manner over the IMS. Instead, according to thepresent invention, the nodes MSC A/B work as ICS gateway for the otherMSCs towards the IMS. As above described, the present invention achievesthis by introducing the use of configuration information that will helpthe cooperation of enhanced and non-enhanced MSCs.

It is noted that the MSCA and MSCB are examples of the serving networkentities described in the third embodiment or of the second networkentity described in the first embodiment. Similarly, the nodes MSC3 orMSC5 are examples of the first network entity according to the firstembodiment or the attaching core network entities of the secondembodiment.

The configuration information, with reference still to FIG. 5, may beimplemented according to this example, in that the MSC A and/or MSC Bwill have the function which indicates to the HLR that the HLR shouldpoint to MSC A or/and MSC B for the user equipment for ICS, until theuser equipment is moved out of the control of MSC A/B.

In one example, the described solution may be optionally applicable tohome network scenarios only. In case the subscriber is roaming to avisited network, according to this example, the VMSC will receive aroaming profile which may be different from the home profile. Theroaming profile might instruct the VMSC to use normal originationprocedure and not to route originating calls to the home IMS.

Returning to FIG. 5, MSCA and MSCB are ICS capable, and MSC3 to MSC7 arenot ICS capable. By configuration, MSCA and MSCB can know which MSCs areto be served for ICS. In this case, it's MSC3 to 7. Also byconfiguration MSC3 to 7 will route all outgoing calls to MSCA or MSCB.In the HLR, MSCA and MSCB are “associated” with MSC3 to 7 for ICS byconfiguration.

When the UE is attached to the CS network (MSC3, see step 1 in FIG. 5),HLR will have its location (following the location update of step 2),and knows that MSCA and MSCB are associated to MSC3 (step 3). The HLRwill then send information to MSCA or MSCB, telling that the UE is up(step 5). For each served MSC (i.e. MSC3 to 7), there will be oneprimary serving MSC associated (such as MSCA) and one secondary servingMSC associated (such as MSCB). In the normal case HLR will send theinformation to the primary serving MSC. If the primary one is failed, itwill then send the information to the secondary MSC. This may be forredundancy reason (it is noted that the two MSC A/B are optional, sincethe invention functions also with only one enhanced MSC). Theinformation sent by HLR can be a new message or some new informationelements (e.g. ICS flag) in an existing message (according to oneexample this may be the Insert Subscriber Data message, ISD, indicatingthe IMSI of the UE and the MSC3 node address), sent from HLR to MSCA/B.This message needs to include the IMSI such that the selected servingMSC can derive the needed IMS user identity (see 3GPP 23.292). Wherebythe MSCA/B will know that the UE is up and its serving MSC is MSC3.MSCA/B will then send IMS registration to IMS domain on behalf of theUE.

With continuous reference to FIG. 6, the steps therein depicted will nowbe illustrated in more detail. The attaching procedure foresees the step2 of performing a location update wherein the MSC 3 to which the userequipment is now attached informs the HLR of the current position of theuser equipment, e.g. that the MSC 3 is the core network node to whichthe user equipment is currently attached. In step 3, the HLR will findthe node which is associated to the MSC 3. In the present case, suchnode is represented by one or both of the nodes MSC A/B as depicted alsoin FIG. 5. Once the associated MSC A/B is found, the HLR will providethe MSC 3 with further information as depicted in step 4. This furtherinformation comprise (optionally) subscriber data and a new informationelement including for instance the MSC A/B addresses (or address of onlyone of them). The information provided in step 4 of FIG. 6 are anexample of the configuration information above described since theyprovide the MSC A/B address (representing an example of the identifyinginformation of the network entities) to the MSC 3 which is now able toestablish a relationship between itself and an enhanced core networknode. Subsequently, with reference to step 5 of FIG. 6, the HLR informsthe MSC A/B (either one or both of the nodes MSC A and MSC B depicted inFIG. 5) that the user equipment is up and that the corresponding servingnode is the node MSC 3. The HLR may at the step 5 optionally alsofurther communicate the subscriber data of the user equipment in orderto inform the MSC A/B.

Following this, the MSC A/B (one of the two nodes according to anexample) is then capable of registering the user equipment in the IMS onthe basis of the information received in step 5.

Consequently, the user equipment is capable of being registered with theIMS even if it is attached to a non-enhanced core network node.

Reference will now be made to FIG. 7, representing a flow of messagesoccurring in correspondence of a mobile originated call following forinstance the attach procedure above described. In step 1, the userequipment places a call indicated as mobile originated MO call. In step2, the decision to route the call to MSCA or B is based onconfiguration, that is, the primary route from MSC3 will point to theprimary serving MSC of MSC3, and the secondary route point to thesecondary serving MSC of MSC3, both as configured in the HLR. Accordingto an example, only when the primary serving MSC fails, the secondaryroute will be used (again, the invention is applicable also to the casewherein only MSCA or MSCB is present). The configuration and rule ofusage in MSC3 (corresponding to the configuration information abovedescribed) has been received from the HLR and it will make sure that thecall will be routed to the correct serving MSC which actually made theregistration in IMS for the UE.

For different MSCs (from MSC3 to 7), the primary and secondary servingMSCs can be different so that load balance between MSCA and MSCB can bereached. This load balance should either be statically configured or,alternatively, it can be easily reached by using, for example, a roundrobin algorithm in HLR to select the primary and the secondary ICScapable MSC upon reception of a Location Update from a non-ICS capableMSC. The usage of two enhanced MSC provides further advantages likeenhanced availability. At step 3, the call party is checked and the callis routed towards the call party in order to complete the operation.

Reference will now be made to FIG. 8, representing the call flow in acase of a mobile terminating call. In step 1, a mobile terminated callarrives at one of or both of the enhanced nodes MSC A/B from the IMS. Instep 2, it is found out which is the serving node (in the presentexample MSC 3) and the call is correspondingly sent to such node. Theprocess of finding out the serving MSC 3 is performed for instance onthe basis of the configuration information providing an associationbetween the enhanced node MSC A or/and MSC B and the non-enhanced nodeMSC 3 to which the user equipment is currently attached. It is notedthat the configuration information may optionally comprise also theinformation identifying the user equipment such that the core networkentities are capable of associating the current information to thecorrect user equipment.

If the user equipment moves to a different MSC, as for instance the MSC8 as depicted in FIG. 8 which is not served by MSC A/B enhanced for ICS,then the HLR will inform the MSC A/B (either one or both of the nodesMSC A and MSC B according to the implementation) about this condition.According to an example, a delete subscriber data MAP operation (VSD)indicating the IMSI of the user equipment and a flag of the known ISCcapable MSC withdrawal is sent. Accordingly, the MSC A/B deregisters theuser equipment in the IMS. The situation is represented in FIG. 9,illustrating the flow of messages for the case of a user equipmentmoving out of the control of an enhanced node like the node MSC A or MSCB. More in detail, in step 1 of FIG. 9 the user equipment attaches tothe non-enhanced node MSC 8. This operation can be performed after theuser equipment switches on or upon moving of the user equipment from aprevious node to which the user equipment was attached to another areaserved by the MSC A. Upon attaching the user equipment, the MSC 8performs a location update with the HLR as indicated in step 2. The HLR,see step 3 of FIG. 9, following the location update finds out that theMSC 8 is not associated with the MSC A or with the MSC B. In otherwords, the HLR finds out that the MSC 8 is not associated with anenhanced network entity capable of performing interworking with the IMS.Therefore, the HLR performs a cancel location with the MSC 3 asindicated in step 4; this means that non enhanced MSC 3 is informed tocancel the location relating to the user equipment UE. In step 5, theHLR sends information to one or both of the nodes MSC A and MSC Binforming it/them to delete subscriber data relating to the userequipment that moves to the area served by MSC 8, as indicated in step 5of FIG. 9. In the same step 5, the MSC A/B is informed that the userequipment UE is out of its/their control. A step 6, the MSC A/Bderegisters the user equipment UE in the IMS. The steps 4 and 5 of FIG.9 are examples of the steps described in the first embodiment whereinthe network entities are informed that they are not anymore associated.

It is noted that terminating calls will be routed from the IMS to theMSC A or B, which in turn will route it to the serving MSC. However,this might be suboptimal. Alternatively, the SCC AS is configured toalways break out terminating calls to the CS domain when the call is notterminated over a PS (packet switched) access. In case of networkscenarios in which also MSC Server enhanced for ICS (TS 23.292) aredeployed, the MSC 1 or 2 can indicate in the registration that thiscontact shall not be used for termination. This indication is then usedby the SCC AS to determine that in case this contact is selected byT-ADS then CS breakout operation shall be used instead of regular IMStermination towards the contact.

When the operator cancels the location for the subscriber, the HLRdetects that the subscriber has ICS flag and is registered in MSC3 andICS capable MSCA/B, so HLR sends a Cancel Location to MSC3 and a newmessage to MSCA/B in order to deregister from IMS (in one example a DSDMAP operation is sent indicating the IMSI of the UE and a flag ofnon-ICS-cap-MSC withdrawal).

FIG. 10 represents a flow of messages relating to the procedure ofadministrative cancel local update. In step 1 the HLR determines that anadministrative cancel location procedure has to be performed.Consequently, in step 2 the HLR finds the MSC associated with the MSCA/B. In step 3, the HLR sends a cancel location request to the MSC 3found in step 2. Afterwards or at the same time, the HLR sends in step 4a message indicating to delete subscriber data and informing that theuser equipment UE is out of the control of the given MSC A/B. In step 5,the MSC A/B deregisters the user equipment UE in the IMS.

According to one example, the existing MAP interface could be enhancedaccording to an example of putting the present invention into practice.For instance, insert subscriber data ISD and delete subscriber data DSDMAP operation can be introduced to carry the ICS information. In orderto transport such information, ISD MAP operations could be modified asin the following according to an example (indicated in bold characters)of putting the present invention into practice:

Insert Subscriber Data MAPV3 Operation Code=7 Class=1 ASN.1 FormalDescription insertSubscriberData OPERATION ::= { -- Timer m ARGUMENTSEQUENCE { imsi [0] IMSI OPTIONAL, COMPONENTS OF  SubscriberData,naea-PreferredCI [15] NAEA-PreferredCI OPTIONAL, gprsSubscriptionData[16] GPRSSubscriptionData OPTIONAL, networkAccessMode [24]NetworkAccessMode OPTIONAL, lmu-Indicator [21] NULL OPTIONAL,lcsInformation [22] LCSInformation OPTIONAL, istAlertTimer [26]IST-AlertTimerValue OPTIONAL, sgsn-CAMEL-SubscriptionInfo [17]SGSN-CAMEL-SubscriptionInfo OPTIONAL, chargingCharacteristics [18]ChargingCharacteristics OPTIONAL, accessRestrictionData [19]AccessRestrictionData OPTIONAL, icsCapableVLR-List [xx]icsCapableVLR-List OPTIONAL, nonilcsCapableVLR -List [xyx] ISDN-AddressStringicsCapableVLR-List OPTIONAL }

naea-PreferredCI is included at the discretion of the HLR operator.

If the Network Access Mode parameter is sent, it shall be present onlyin the first sequence if segmentation is used.

RESULT SEQUENCE { teleserviceList [1] TeleserviceList OPTIONAL,bearerServiceList [2] BearerServiceList OPTIONAL, ss-List [3] SS-ListOPTIONAL, odb-GeneralData [4] ODB-GeneralData OPTIONAL,regionalSubscriptionResponse [5] RegionalSubscriptionResponse OPTIONAL,supportedCamelPhases [6] SupportedCamelPhases OPTIONAL,extensionContainer [7] ExtensionContainer OPTIONAL, ...} -- optionalERRORS { dataMissing| unexpectedDataValue| unidentifiedSubscriber } CODElocal:7 } where icsCapableVLR-List ::= SEQUENCE SIZE(1..maxNumOfICSVLRs) OF ISDN-AddressString maxNumOfICSVLRs INTEGER ::= nwhere

It is noted that in the above and below examples expressions like “XX”,“XZ” represent placeholders for actual or real information elementnumbers to be determined according to circumstances or as determined forinstance according to an applicable standard.

In the above example, it is noted that maxNumOfICSVLRs value needs to bestated. Minimum value may be 2 due to redundancy but maximum is notspecified.

It is also noted that Only ISD MAPV3 is shown in this invention but ISDMAPV1 and MAPV2 should also be upgraded similarly.

In order to transport ICS information, the DSD MAP operation may berealized as in the following by way of example (indicated in boldcharacters):

Delete Subscriber Data (HLR-->VLR/SGSN) Operation Code=8 Class=1 ASN.1Formal Description deleteSubscriberData OPERATION ::= { --Timer mARGUMENT  SEQUENCE { imsi  [0] IMSI, basicServiceList  [1]BasicServiceList OPTIONAL, ss-List  [2] SS-List OPTIONAL,roamingRestrictionDueToUnsupportedFeature  [4] NULL OPTIONAL,regionalSubscriptionIdentifier  [5] ZoneCode OPTIONAL,camelSubscriptionInfoWithdraw  [9] NULL OPTIONAL,gprsSubscriptionDataWithdraw [10] GPRSSubscriptionDataWithdraw OPTIONAL,gmlc-ListWithdraw [13] NULL OPTIONAL, istInformationWithdraw [14] NULLOPTIONAL, specificCSI-Withdraw [15] SpecificCSI-Withdraw OPTIONAL, nonIcsCapableVLRWithdraw [xz] NULL OPTIONAL } RESULT SEQUENCE {regionalSubscriptionResponse  [0] RegionalSubscriptionResponse OPTIONAL,extensionContainer ExtensionContainer OPTIONAL, }  -- optional ERRORS {dataMissing| unexpectedDataValue| unidentifiedSubscriber } CODE local:8}

According to the previous considerations, Insert Subscriber Data MAPoperation may now optionally transport:

Associated ICS-capable MSCs information towards the MSC non-ICS capablewhere the subscriber is currently located.

Associated non-ICS-capable MSCs information towards the MSC ICS capablewhere the subscriber is currently located.

According to the previous considerations, Delete Subscriber Data MAPoperation must now optionally transport:

Associated non-ICS-capable MSCs information towards the MSC ICS capablewhere the subscriber is currently located.

The above described behavior may be summarized for each Use case in thetable below:

Use case Direction Message Recommended attributes UE AttachHLR−>non_ICS_cap_MSC ISD IMSI, icsCapableVLR-List, Procedure and anyother attribute (e.g. FIG. 5) needed in the update location procedureHLR−>ICS_cap_MSC ISD IMSI, nonIcsCapableVLR UE moving out ofHLR−>ICS_cap_MSC DSD IMSI, the control of nonIcsCapableVLRWithdrawICS-cap-MSC (e.g. FIG. 9) Administrative HLR−>ICS_cap_MSC DSD IMSI,Cancel Local nonIcsCapableVLRWithdraw Update (e.g. FIG. 10)

The above table illustrates attributes carried in the concerned MAPoperations for each Use Case according to an example illustrating thefunctioning of the invention.

According to one example, it is possible to centralize the configurationof the relationship among ICS capable MSCs and non-ICS capable MSCs inHLR only, so the MSCs are not aware of that relation until traffichappens. For instance, a table as follows can be implemented in the HLR:

MSC Number Primary ICS cap MSC Secondary ICS cap MSC MSC-1 MSC-ICS-1MSC-ICS-n MSC-2 MSC-ICS-2 MSC-ICS-(n − 1) . . . . . . . . . MSC-nMSC-ICS-n MSC-ICS-1 MSC-(n + 1) . . . MSC-m

The above table shows an example where there are m MSCs totally. Some ofthem are ICS enhanced (whose number may be bigger than n, but can't bebigger than m), among those MSCs n MSCs (shown as MSC-ICS in the abovetable) are appointed as serving MSCs for the non-ICS MSCs. The secondaryICS capable MSC is allocated in a reverse order, as an example. Whenredundancy wants to be achieved, n may be equal or bigger than 2. Eventhough only MSCA and MSCB are covered along this invention, the numberof MSC ICS capable is not restricted to two. This invention is alsoapplicable to the case of having more than two MSC ICS capable in thenetwork.

The above table provides an example of implementing the configurationinformation. In that case, the configuration information specifiesassociation between non enhanced MSCs and two or more enhanced MSCs.However, as already explained previously, the configuration informationmay also comprise an association only between a non-enhanced MSC and anenhanced MSC. Alternatively, the configuration information may simplyindicate to one non enhanced node the address of an associated enhancednode or vice versa. Furthermore, the table is only a way of representingthe configuration information: in fact, the same can be implemented bymeans of other types of data structures (e.g. lists) according tocircumstances.

Furthermore, the table can be implemented in an analysis tree algorithm.This table above is statically created by configuration. Alternatively,this table can be dynamically created by means of having a list ofnon-ICS capable MSCs, a second list with ICS capable MSCs and creatingthe association between these two types of MSCs upon reception of LU perUE by using, for example, a round robin algorithm. This method will endin a well-balanced distribution.

There is a category for an ICS capable subscriber, as for instancespecified in appropriate standards like in the TS 23.292.

The process according to a further example of the present invention canbe described as follows:

1 When a subscriber updates the location in HLR, the HLR gets thesubscriber info and checks the ICS Capable category.2 If the subscriber is ICS capable, then the MSC number, e.g. MSC3,received in the LU message is analyzed.3 If the MSC3 is in the table (i.e. found in the configurationinformation) then it has MSCA/B assigned.4 HLR gets MSCA/B and MSC3 and stores internally that locationinformation.5 It sends an Insert Subscriber Data to MSC3 with a new proprietaryparameter indicating the MSCA/B address.6 It sends another new message to MSCA/B indicating IMSI, MSC3 address,status info (reg or dereg) and may be more info.7 From then on MSCA/B knows about the MSC3 for this subscriber.8 MSC3 knows about MSCA/B for the subscriber.9 And the same for HLR who knows and keeps all the relationship.

The present invention achieves several advantages like for instance:

Allowing the ICS deployment with minimum impact on the existing CSnetwork.

Providing a cost efficient and simple to implement ICS solution if theoperator chooses to migrate its CS subscribers to ICS over a long periodof time.

Providing an HLR based routing method, instead of using CAMEL.

Improved interaction among enhanced and non-enhanced MSCs.

With reference to the advantages over CAMEL based solution the followingis in fact noted. Some alternative techniques are known in the state ofthe art commonly addressed as CS to IMS overlays. They make use ofCAMEL/Intelligent network services to perform the interfacing towardsIMS. In this technique no enhanced MSCs are needed because thetranslation is performed by an IN application on the SCP. The INinterface is invoked by OICK or OCSI service indicators in thesubscription in the HLR. According to the present invention, to thecontrary, an easier and more flexible implementation can be achieved.

In the above description, reference has been made to network entities orcomponent entities (like to communication entity or the storage entity).It is recalled that these entities can be indifferently implemented inone network node or network device or may be implemented in a pluralityof network nodes of devices in which the necessary functionalities aredistributed in a suitable way.

Moreover, as evident to the reader, the several embodiments and featuresthereof can be exchanged as necessary. The several examples may befurther combined as necessary, as the reader would recognize that anycombination thereof (or of parts thereof) is possible without any needto substantial modifications to what has been described.

The invention has been described in relation to particular embodimentsand examples which are intended in all aspects to be illustrative ratherthan restrictive. Those skilled in the art will appreciate that manydifferent combinations of hardware, software and firmware will besuitable for practicing the present invention. Moreover, otherimplementations of the invention will be apparent to those skilled inthe art from consideration of the specification and practice of theinvention disclosed herein. It is intended that the specification andthe examples be considered as exemplary only. To this end, it is to beunderstood that inventive aspects lie in less than all features of asingle foregoing disclosed implementation or configuration. Thus, thetrue scope and spirit of the invention is indicated by the followingclaims.

Where the terms like communication entity, storage entity or forwardingentity are used herewith, no restriction is made regarding howdistributed these elements may be and regarding how gathered elementsmay be. That is, the constituent parts of a unit or element or entitymay be distributed in different software or hardware components ordevices for bringing about the intended function. A plurality ofdistinct elements may also be gathered for providing the intendedfunctionalities.

Any one of the above-referred entity of a network entity, or an element,or a network device, or a network node, etc. . . . may be implemented inhardware, software, field-programmable gate array (FPGA),application-specific integrated circuit (ASICs), firmware or the like.

In further embodiments of the invention, any one of the above-mentionedand/or claimed parts like controller or receiver (this list being notexhaustive) may be replaced by corresponding controlling means orreceiving means.

What is claimed is:
 1. A method for handling core network entities of a radio core communications network, the radio core communications network comprising a first network entity and a second network entity, wherein the second network entity differs from the first network entity in that it is capable of processing inter-working between messages exchanged with the radio core communications network and messages exchanged with an IP multimedia subsystem, the method comprising the steps of: providing at least one amongst the first and second network entities with configuration information, the configuration information indicating a relationship between the first and second core network entities; routing messages relating to calls established between a first user terminal attached to the first network entity and a second user terminal attached to the IP multimedia subsystem according to the configuration information.
 2. The method of claim 1: wherein the configuration information comprises first identification information identifying at least the second network entity; wherein the routing messages is performed at the first core network entity and comprises routing messages originating from the first user terminal to the second core network entity according to the first identification information.
 3. The method of claim 2, wherein the first identification information identifies at least a further network entity capable of performing the inter-working.
 4. The method of claim 1: wherein the configuration information comprises second identification information identifying at least the first network entity; and wherein the routing messages is performed at the second core network entity and comprises routing messages terminating at the first user terminal according to the second identifying information.
 5. The method of claim 1, wherein the relationship between the first and second core network entities is that the second network entity is a serving network entity for the first network entity.
 6. The method of claim 1, wherein the relationship between the first and second core network entities is that the second network entity is not a serving network entity for the first network entity.
 7. The method of claim 1, further comprising updating the configuration information when the first user terminal detaches from the first core network entity and attaches to another core network entity.
 8. The method of claim 1, wherein the second network entity registers the second user terminal with the IP multimedia subsystem.
 9. An attaching core network entity for a radio core communications network, the attaching core network entity comprising: a communication entity configured to exchange messages relating to calls associated with a first user terminal attached to the attaching core network entity through a radio network interface; a storage entity for configured to store configuration information indicating a relationship between the attaching core network entity and one further core network entity, wherein the attaching core network entity differs from the further core network entity in that the further core network entity is adapted to process inter-working between messages exchanged with the radio core communications network and messages exchanged with the IP multimedia subsystem; wherein the communication entity is further configured to route the messages according to the configuration information.
 10. The attaching core network entity of claim 9: wherein the configuration information comprises first identification information identifying at least the further network entity; wherein the communication entity is further configured to route messages originating from the first user terminal to the further core network entity according to the first identification information.
 11. The attaching core network entity of claim 9, wherein the first identification information identifies at least another network entity capable of performing the inter-working.
 12. A serving core network entity for a radio core communications network, the serving core network entity comprising: a processing entity configured to process inter-working between messages exchanged with the radio core communications network and messages exchanged with an IP multimedia subsystem; a forwarding entity configured to forward messages associated with a first user terminal attached to an attaching core network entity, wherein the serving core network entity differs from the attaching core network entity in that the serving core network entity comprises the processing entity; a storage entity configured to store configuration information indicating a relationship between the serving core network entity and the attaching core network entity; wherein the forwarding entity is further configured to forward the messages according to the configuration information.
 13. The serving core network entity of claim 12, wherein the messages comprise messages relating to calls associated with the first user terminal.
 14. The serving core network entity of claim 12, wherein the messages comprise at least a registration message for registering the first user terminal with the IP multimedia subsystem on the basis of the configuration information.
 15. A serving core network entity of claim 12: wherein the configuration information comprises identification information identifying at least the one attaching network entity; and wherein the forwarding entity is configured to route messages terminating at the first user terminal according to the second identifying information. 